offsec.nl - Healthcheck analysis

Ensure that the NTLMv1 and old LM protocols are banned

S-OldNtlm

The purpose is to check if NTLMv1 or LM can be used by DC

NTLMv1 is an old protocol which is known to be vulnerable to cryptographic attacks.
It is typically used when an hacker sniff the network and tries to retrieve NTLM hashes which can then be used to impersonate users.

This attack can be combined with Coerced authentication attacks - an hacker forces the DC to connect to a controlled host.
In this case, NTLMv1 can be specified so the hacker can retrieve the NTLM hash of the DC, impersonates it and then take control of the domain.
This attack is still possible with NTLMv2 but this is more difficult.

Windows have default security settings regarding LM/NTLM. Windows XP: Send LM & NTLM responses, Windows 2003: Send NTLM response only, Vista/2008: Win7/2008 R2: Send NTLMv2 response only.

However Domain Controllers are relaxed settings to accept the connection of older operating systems.
That means that by default, NTLMv1 is accepted on domain controllers.
If no GPO defines the LAN Manager Authentication Level, the DC fallback to the non secure default.

After an audit of NTLMv1 usage (see the links below), you need to raise the LAN Manager Authentication Level to "Send NTLMv2 response only. Refuse LM & NTLM".
This can be done by editing the policy "Network security: LAN Manager authentication level" which can be accessed in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
The policy will be applied after a computer reboot.

As an alternative, the well known script Get-NtlmV1LogonEvents.ps1 can be used to search for NTLMv1 logon events.

Beware that you may break software which is not compatible with Ntlmv2 such as old Linux stack or old Windows before Windows Vista.
But please note that Ntlmv2 can be activited on all Windows starting Windows 95 and other operating systems.

15 points if present

https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/audit-domain-controller-ntlmv1
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level
https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-ntlm-2-authentication
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R37 [paragraph.3.6.2.1]

The detail can be found in Security settings

Check the process of registration of computers to the domain

S-ADRegistration

The purpose is to ensure that basic users cannot register extra computers in the domain

By default, a basic user can register up to 10 computers within the domain. This default configuration represents a security issue as basic users shouldn't be able to create such accounts and this task should be handled by administrators.

Note: this program checks also the GPO for SeMachineAccountPrivilege assignment. This assignment can be used to restrict the impact of the key ms-DS-MachineAccountQuota.

To solve the issue, limit the number of extra computers that can be registered by a basic user. It can be reduced by modifying the value of ms-DS-MachineAccountQuota to zero (0). Another solution can be to remove altogether the authenticated users group in the domain controllers policy. Do note that if you need to set delegation to an account so it can add computers to the domain, it can be done through 2 methods: Delegation in the OU or by assigning the SeMachineAccountPrivilege to a special group

10 points if present

https://docs.microsoft.com/troubleshoot/windows-server/identity/default-workstation-numbers-join-domain
http://prajwaldesai.com/allow-domain-user-to-add-computer-to-domain/
http://blog.backslasher.net/preventing-users-from-adding-computers-to-a-domain.html
[MITRE]Mitre Att&ck - Mitigation - User Account Management

Check if all admin accounts require kerberos pre-authentication

S-NoPreAuthAdmin

The purpose is to ensure that all admin accounts require kerberos pre-authentication

Without kerberos pre-authentication, an attacker can request kerberos data from the domain controller and use this data to brute-force the account password. You can search accounts using the ldap query (userAccountControl:1.2.840.113556.1.4.803:=4194304)

Edit the property of the involved accounts and select the Account tab. Uncheck "Do not require Kerberos preauthentication". For computers which doesn't have the Account tab, you have to manually edit the attribute useraccountcontrol. Subtract from the attribute the value 4194304.

5 points per discovery

http://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting
[FR]ANSSI - Kerberos pre-authentication disabled for privileged accounts (vuln1_kerberos_properties_preauth_priv)1

The detail can be found in User information and Computer information

Check if all accounts require kerberos pre-authentication

S-NoPreAuth

The purpose is to ensure that all accounts require kerberos pre-authentication

Without kerberos pre-authentication, an attacker can request kerberos data from the domain controller and use this data to crack the account password. You can find which accounts don't require Kerberos pre-authentication with the PowerShell command: Get-ADObject -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=4194304)"

Edit the property of the involved accounts and select the Account tab. Uncheck "Do not require Kerberos preauthentication". For computers which doesn't have the Account tab, you have to manually edit the attribute useraccountcontrol. Subtract from the attribute the value 4194304.

5 points if present

http://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
[MITRE]T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting
[FR]ANSSI - Kerberos pre-authentication disabled (vuln2_kerberos_properties_preauth)2

The detail can be found in User information and Computer information

Check for completeness of network declaration

S-DC-SubnetMissing

The purpose is to ensure that the minimum set of subnet(s) has been configured in the domain

When multiple sites are created in a domain, networks should be declared in the domain in order to optimize processes such as DC attribution. In addition, PingCastle can collect the information to be able to build a network map. This rule has been triggered because at least one domain controller has an IP address which was not found in subnet declaration. These IP addresses have been collected by querying the DC FQDN IP address in both IPv6 and IPv4 format.

Locate the IP address which was found as not being part of declared subnet then add this subnet to the "Active Directory Sites" tool. If you have found IPv6 addresses and it was not expected, you should disable the IPv6 protocol on the network card.

5 points if present

[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration

The detail can be found in Domain controllers

Check that there is no account with never-expiring passwords

S-PwdNeverExpires

The purpose is to ensure that every account has a password which is compliant with password expiration policies

Some accounts have passwords which never expire. Should an attacker compromise one of these accounts, he would be able to maintain long-term access to the Active Directory domain.

We have noted that some Linux servers, domain joined, are configured with a password which never expires.
This is a misconfiguration because a password change can be configured. It was however not the default on some plateform.
See one of the link below for more information.

In order to make Active Directory enforce periodic password change, accounts must not have the "Password never expires" flag set in the "Account" tab of the user properties. Their passwords should then be rolled immediately.
For services accounts, Windows provide the "managed service accounts" and "group managed service accounts" features to facilite the automatic change of passwords.
Please note that there is a document in the section below which references solutions for service accounts of well known products.
Also Linux servers should be configured with automatic machine account change.

1 points if present

https://adsecurity.org/?p=4115
https://access.redhat.com/discussions/1283873
[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Accounts with never-expiring passwords (vuln2_dont_expire)2

The detail can be found in User information

Ensure that DC supports kerberos armoring when functional level is at least Windows 2012

S-KerberosArmoringDC

The purpose is to ensure that DC supports kerberos armoring when functional level is at least Windows 2012

Kerberos Armoring is an optimization of the kerberos protocol. It avoids the preauthentication steps thus prohibiting preauthentication attacks;
It is supported only starting Windows 2012 DC and Windows 8 workstations.
If kerberos armoring is requested for other operating systems (such as Windows 7 or Linux), the kerberos authentication protocol may refuse to work.

To enable kerberos armoring for domain controllers, edit the GPO and go to Computer Configuration > Administrative Templates > System > KDC
then enable the policy "KDC support for claims, compound authentication and Kerberos armoring".
The policy should be set to at least "Supported".

The safest settings is "Fail authentication requests when Kerberos armoring is not available" but it should be enabled only if the clients support kerberos armoring.

Informative rule (0 point)

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831747(v=ws.11)
https://pupuweb.com/solved-how-enable-kerberos-armoring-eap-fast-ad/
[MITRE]T1558 Steal or Forge Kerberos Tickets

If activated, the detail can be found in Security settings

Ensure that clients supports kerberos armoring when functional level is at least Windows 2012

S-KerberosArmoring

The purpose is to ensure that clients supports kerberos armoring when functional level is at least Windows 2012

Kerberos Armoring is an optimization of the kerberos protocol. It avoids the preauthentication steps thus prohibiting preauthentication attacks;
It is supported only starting Windows 2012 DC and Windows 8 workstations.
If kerberos armoring is requested for other operating systems (such as Windows 7 or Linux), the kerberos authentication protocol may refuse to work.

To enable kerberos armoring for client, edit the GPO and go to Computer Configuration > Administrative Templates > System > Kerberos
then enable the policy "Kerberos client support for claims, compound authentication and Kerberos armoring".

Informative rule (0 point)

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831747(v=ws.11)
https://pupuweb.com/solved-how-enable-kerberos-armoring-eap-fast-ad/
[MITRE]T1558 Steal or Forge Kerberos Tickets

If activated, the detail can be found in Security settings

A Delegation is granted to Everyone

P-DelegationEveryone

The purpose is to verify that there is no delegation granted to "Everyone" and to "Authenticated Users"

To delegate control to a OU, access checks can be modified. In case of a misconfiguration, access can be granted to the group "Everyone" or "Authenticated Users".

Review the delegation to remove this permission and if needed, set a more targeted group as recipient of the delegation.

15 points per discovery

[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[US]STIG V-2370 - The access control permissions for the directory service site group policy must be configured to use the required access permissions.
[MITRE]T1187 Forced Authentication
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R18 [subsubsection.3.3.2]

The detail can be found in Delegations

Check for inactive Administrator Accounts

P-Inactive

The purpose is to ensure that the Administrator Accounts in the AD are all necessary and used

Accounts within the AD have attributes indicating the creation date of the account and the last login of this account. Accounts which haven't have a login since 6 months or created more than 6 months ago without any login are considered inactive. If an Administrator Account is set as inactive, the reason for having Administrator rights should be strongly justified.

To correct the situation, you should make sure that all your Administrator Account(s) are "Active", meaning that you should remove Administrator rights if an account is set as not "Active"

30 points if the occurence is greater than or equals than 30
then 20 points if the occurence is greater than or equals than 15

[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R36 [subsection.3.6]

Check if there is a control path involving everyone-like groups.

P-ControlPathIndirectEveryone

The purpose is to ensure that there is no control path involving everyone.

If you have access to a key server and the helpdesk can reset your password, then the helpdesk has access to the key server.
This is the kind of logic used by hackers to take control of the domain using key infrastructure objects (domain root, ...) or groups (domain administrators, ...).
Permissions are collected and analyzed to produce a control paths analysis.
Only write permissions (and specific ones) are used for this analysis.
Then the program identifies which users or computers, that are not members of known groups, can take control of this object.
To be fast, some tradeoffs have been selected. For example, logged on users on servers are ignored.
The program may also select paths which are not exploitable and ignore paths if it cannot read every permissions.
[Everyone] includes the anonymous, everyone, authenticated users, domain users, domain computers and builtin-users groups.

You should analyze the chart and determine which underlying object is involved and grants write permissions to everyone.
Then edit the permissions and locate the write permission involved.
Then delete it or replace it according to your delegation model.

25 points if present

https://github.com/BloodHoundAD/BloodHound
https://github.com/ANSSI-FR/AD-control-paths
[MITRE]T1069.002 Permission Groups Discovery: Domain Groups

The detail can be found in Control Paths Analysis

Check if there is a control path involving too much users or computers.

P-ControlPathIndirectMany

The purpose is to check if users can abuse their write access to obtain additional privileges.

If you have access to a key server and the helpdesk can reset your password, then the helpdesk has access to the key server.
This is the kind of logic used by hackers to take control of the domain using key infrastructure objects (domain root, ...) or groups (domain administrators, ...).
Permissions are collected and analyzed to produce a control paths analysis.
Only write permissions (and specific ones) are used for this analysis.
Then the program identifies which users or computers, that are not members of known groups, can take control of this object.
To be fast, some tradeoffs have been selected. For example, logged on users on servers are ignored.
The program may also select paths which are not exploitable and ignore paths if it cannot read every permissions.

You should analyze the chart and determine which underlying object is involved and grants too much write permissions.
Then edit the permissions and locate the write permission involved.
Then delete it or replace it according to your delegation model.

25 points if the occurence is greater than or equals than 200
then 15 points if the occurence is greater than or equals than 100
then 10 points if the occurence is greater than or equals than 50
then 5 points if the occurence is greater than or equals than 20

https://github.com/BloodHoundAD/BloodHound
https://github.com/ANSSI-FR/AD-control-paths
[MITRE]T1069.002 Permission Groups Discovery: Domain Groups

The detail can be found in Control Paths Analysis

At least one Administrator Account can be delegated

P-Delegated

The purpose is to ensure that all Administrator Accounts have the configuration flag "this account is sensitive and cannot be delegated" (and are not member of the built-in group "Protected Users" when your domain functional level is at least Windows Server 2012 R2).

Without the flag "This account is sensitive and cannot be delegated" any account can be impersonated by some service account. It is a best practice to enforce this flag on administrators accounts.

To correct the situation, you should make sure that all your Administrator Accounts has the check-box "This account is sensitive and cannot be delegated" active or add your Administrator Accounts to the built-in group "Protected Users" if your domain functional level is at least Windows Server 2012 R2 (some functionalities may not work properly afterwards, you should check the official documentation).
If you want to enable the check-box "This account is sensitive and cannot be delegated" but this is not possible because the box is not present (typically for GMSA account), you can add the flag manually by adding the number 1048576 to the attribute useraccountcontrol of the account.
Please note that there is a section below in this report named "Admin Groups" which give more information.

20 points if present

[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[US]STIG V-36435 - Delegation of privileged accounts must be prohibited.

The detail can be found in Admin Groups

Check for Native administrator usage

P-AdminLogin

The purpose is to verify if the Native Administrator account is used.

The Native Administrator account is the main administrator account, and it is sharing its password with Directory Services Restore Mode password. Since it is the same password, it can be used to take control of the domain even if the account is disabled, notably through a DSync attack. The last login date is retrieved through the LastLogonTimestamp LDAP attribute retrieved from the Active Directory. There is an exception for 35 days to avoid this rule to be triggered at the domain creation.

To mitigate the security risk, a good practice is to use the Native Administrator account only for emergency, while the daily work is performed through other accounts.
It is indeed strongly recommended to not use this account but to use nominative account for administrators and dedicated account for services.
Do note that the anomaly will be removed 35 days after the last native administrator login.

To track where the administrator account has been used for the last time, we recommend to extract the attribute LastLogon of the administrator account on ALL domain controllers.
It can be done with tools such as ADSIEdit or ADExplorer.
Then, for each domain controller, extract the events 4624 at the date matching the LastLogon date. You will identify the computer and the process at the origin of the logon event.

If the LastLogon attribute is older for ALL domain controllers than the LastLogonTimestamp, the LastLogonTimestamp attribute (that PingCastle relies on) may be updated by the kerberos S4u2Self mechanism.
This can be triggered in the Advanced Security Settings properties of any securable objects such as a file, then select the Effective Access tab and click on View effective access.
You have to use replication metadata info to find which DC updated this attribute and look for 4769 and 4624 events on this DC to know who have run this action.
Read the page referenced in the documentation section for more information.

Please note that PingCastle relies on the attribute LastLogonTimestamp to perform this check. The LastLogonTimestamp attribute is replicated but has a latency of a maximum of 14 days, while LastLogon is updated at each logon and is more accurate but not replicated.
The attribute ms-DS-Logon-Time-Sync-Interval can be used to lower or increase the replication delay.

20 points if the occurence is strictly lower than 35

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/ba-p/257135
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

Check if Service Accounts (aka accounts with never expires password) are domain administrators

P-ServiceDomainAdmin

The purpose is to check for accounts with non expiring passwords in the "Domain Administrator" group

PingCastle is checking accounts with never expires password that are mostly used as service accounts.
"Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in kerberoast attacks.

Accounts with never expires passwords are mostly service accounts.
To mitigate the security risk, it is strongly advised to lower the privileges of the "Service Accounts", meaning that they should be removed from the "Domain Administrator" group, while ensuring that the password of each and every "Service Account" is higher than 20 characters

15 points if the occurence is greater than or equals than 2

[US]STIG V-36432 - Membership to the Domain Admins group must be restricted to accounts used only to manage the Active Directory domain and domain controllers.
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[MITRE]T1003.004 OS Credential Dumping: LSA Secrets
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R11 [subsection.2.5]
[FR]ANSSI - Privileged accounts with never-expiring passwords (vuln1_dont_expire_priv)1

The detail can be found in Admin Groups

Avoid unexpected schema modifications which could result in domain rebuild

P-SchemaAdmin

The purpose is to ensure that no account can make unexpected modifications to the schema

The group "Schema Admins" is used to give permissions to alter the schema. Once a modification is performed on the schema such as new objects, it cannot be undone. This can result in a rebuild of the domain. The best practice is to have this group empty and to add an administrator when a schema update is required then to remove this group membership.

Remove the accounts or groups belonging to the "schema administrators" group.

10 points if present

[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R13 [subsection.3.2]
[US]STIG V-72835 - Membership to the Schema Admins group must be limited
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

The detail can be found in Admin Groups

Ensure that the Recycle Bin feature is enabled

P-RecycleBin

The purpose is to ensure that the Recycle Bin feature is enabled

The Recycle Bin avoids immediate deletion of objects (which can still be partially recovered by its tombstone). This lowers the administration work needed to restore. It also extends the period where traces are available when an investigation is needed.

First, be sure that the forest level is at least Windows 2008 R2.
You can check it with Get-ADForest or in the Domain Information section.
Then you can enable it using the PowerShell command:
Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target 'test.mysmartlogon.com'

10 points if present

https://enterinit.com/powershell-enable-active-directory-recycle-bin
[MITRE]Mitre Att&ck - Mitigation - Audit

The detail can be found in Domain Information

Check if all privileged accounts are in the special group Protected Users.

P-ProtectedUsers

The purpose is to ensure that all privileged accounts are in the Protected User security group

The Protected User group is a special security group which automatically applies protections to minimize credential exposure. starting with Windows 8.1. Older Operating System must be updated to take this protection in account such as the Windows 7 KB2871997 patch.
For admins, it:
- Disables NTLM authentication
- Reduces Kerberos ticket lifetime
- Mandates strong encryption algorithms, such as AES
- Prevents password caching on workstations
- Prevents any type of Kerberos delegation

Please also note that a few links (see below) recommends that at least one account is kept outside of the group Protected Users in case there is a permission problem.
That's why this rule is not triggered if only one account is not protected.

After having reviewed the potential impact on adding users to this group, add the missing privileged accounts to this group.

10 points if the occurence is greater than or equals than 2

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
https://blog.netwrix.com/2015/02/20/add-sensitive-user-accounts-to-active-directory-protected-users-group/
https://dirteam.com/sander/2014/11/25/ten-things-you-need-to-be-aware-of-before-using-the-protected-users-group/
https://blog.andreas-schreiner.de/2018/09/07/active-directory-sicherheit-teil-1-privilegierte-benutzer/
[MITRE]Mitre Att&ck - Mitigation - Privileged Process Integrity
[US]STIG V-78131 - Accounts with domain level administrative privileges must be members of the Protected Users group in domains with a domain functional level of Windows 2012 R2 or higher.
[FR]ANSSI - Privileged accounts outside of the Protected Users group (vuln3_protected_users)3
[FR]ANSSI CERTFR-2017-ALE-012

The detail can be found in Admin Groups

Check the Allowed RODC Password Replication Group group

P-RODCAllowedGroup

The purpose is to ensure that the Allowed RODC Password Replication Group group is empty.

Accounts belonging to the Allowed RODC Password Replication Group group have their password hashes revealed on all RODCs.

This group should be emptied, and dedicated groups should only be added to the Password Replication Policy of each relevant RODC.

5 points if present

[MITRE]Mitre Att&ck - Mitigation - Active Directory Configuration
[FR]ANSSI - Dangerous configuration of replication groups for read-only domain controllers (RODCs) (allow) (vuln3_rodc_allowed_group)3

Check that operators group are empty

P-OperatorsEmpty

The purpose is to ensure that the operator groups, which can have indirect control to the domain, are empty

Operator groups (account operators, server operators, ...) can take indirect control of the domain. Indeed these groups have write access to critical resources of the domain.

It is recommended to have these groups empty. Assign administrators into administrators group. Other accounts should have proper delegation rights in an OU or in the scope they are managing.

Informative rule (0 point)

[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[FR]ANSSI - Recommandations de sécurité relatives à Active Directory - R27 [subsection.3.5]

The detail can be found in Admin Groups

Check if the Dns Admins group is not empty

P-DNSAdmin

The purpose is to ensure that the Dns Admin group is not used

Administrators of the DNS Service have the possibility to inject a DLL in this service.
However this service is hosted most of the time in the domain controller and is running as system.
That means that DNS Admins are potentially domain admins.

The security descriptor used to grant admin rights is located on the nTSecurityDescriptor attribute of the object CN=MicrosoftDNS,CN=System.
The "Write All Prop" access right induces the vulnerability.

In this case, the DnsAdmins group is not empty and grant to its user, the possibility to interact with the DNS Service.

Rule update:
The Path Tuesday of October 2021 fixed this vulnerability and assigned it the identifier CVE-2021-40469.
If the patch has been applied, there is no additional mitigation to perform.

This rule is transformed into an informative rule in PingCastle 2.10.1 and will be removed in future versions of PingCastle.

You should remove the members of the DNS admin group and do a proper delegation to the specific DNS Zones.

First, grant only "Read Property", "List", "List object" and "Read permssions" to CN=MicrosoftDNS,CN=System to enable access to the RPC service.

Then on each zone (the object in the tree below with the class dnsZone), grant "Read Property", "List", "List object", "Read permissions", "Create Child", "Delete Child", "Delete", "Delete Tree".

Informative rule (0 point)

https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/007efcd2-2955-46dd-a59e-f83ae88f4678
[FR]ANSSI - DnsAdmins group members (vuln4_dnsadmins)4
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management

The detail can be found in Admin Groups

Check if the LAPS tool to handle the native local administrator password is installed

A-LAPS-Not-Installed

The purpose is to make sure that there is a proper password policy in place for the native local administrator account.

LAPS (Local Administrator Password Solution) is the advised solution to handle passwords for the native local administrator account on all workstations, as it is a simple way to handle most of the subject.

If you don't have any provisioning process or password solution to manage local administrators, you should install the LAPS solution. If you mitigate the risk differently, you should add this rule as an exception, as the risk is covered.

15 points if present

https://www.microsoft.com/en-us/download/details.aspx?id=46899
[MITRE]Mitre Att&ck - Mitigation - Privileged Account Management
[US]STIG V-36438 - Local administrator accounts on domain systems must not share the same password.
[FR]ANSSI CERTFR-2015-ACT-046
[MITRE]T1078.003 Valid Accounts: Local Accounts

The detail can be found in LAPS

Check for the last backup date according to Microsoft standard

A-BackupMetadata

The purpose is check if the backups are actually up to date in case they are needed. The alert can be triggered when a domain is backed up using non-recommended methods

A verification is done on the backups, ensuring that the backup is performed according to Microsoft standards. Indeed at each backup the DIT Database Partition Backup Signature is updated.  If for any reasons, backups are needed to perform a rollback (rebuild a domain) or to track past changes, the backups will actually be up to date. This check is equivalent to a REPADMIN /showbackup *.

Plan AD backups based on Microsoft standards. These standards depend on the Operating System. For example with the wbadmin utility: wbadmin start systemstatebackup -backuptarget:d:

15 points if the occurence is greater than or equals than 7

https://technet.microsoft.com/en-us/library/jj130668(v=ws.10).aspx
[MITRE]Mitre Att&ck - Mitigation - Data Backup
[US]STIG V-25385 - Active Directory data must be backed up daily for systems with a Risk Management Framework categorization for Availability of moderate or high. Systems with a categorization of low must be backed up weekly.

The detail can be found in Backup

Check for Short password length in password policy

A-MinPwdLen

The purpose is to verify if the password policy of the domain enforces users to have at least 8 characters in their password

A check is performed to identify if the GPO regarding password policy allows less than 8 characters password. Short passwords represents a high risk because they can fairly easily be brute-forced. Most CERT and agencies advises for at least 8 characters (and often this number goes up to 12)

To solve the issue, the best way is to either remove the GPO enabling short password, or to modify it in order to increase the password length to at least 8 characters

10 points if present

https://www.microsoft.com/en-us/research/publication/password-guidance/
[FR]ANSSI - Privileged group members with weak password policy (vuln2_privileged_members_password)2
[MITRE]T1201 Password Policy Discovery

The detail can be found in Password policies

Ensure that the printer spooler cannot be abused to get the DC Credentials

A-DC-Spooler

The purpose is to ensure that credentials cannot be extracted from the DC via its printer spooler

When there's an account with unconstrained delegation configured (which is fairly common) and the Print Spooler service running on a computer, you can get that computers credentials sent to the system with unconstrained delegation as a user. With a domain controller, the TGT of the DC can be extracted allowing an attacker to reuse it with a DCSync attack and obtain all user hashes and impersonate them.

The spooler service should be deactivated on domain controllers. Please note as a consequence that the Printer Pruning functionality (rarely used) will be unavailable.

10 points if present

https://adsecurity.org/?p=4056
https://www.slideshare.net/harmj0y/derbycon-the-unintended-risks-of-trusting-active-directory
[MITRE]T1187 Forced Authentication

The detail can be found in Domain controllers

Check if there is the expected audit policy on domain controllers.

A-AuditDC

The purpose is to ensure that the audit policy on domain controllers collect the right set of events.

To detect and mitigate an attack, the right set of events need to be collected.
The audit policy is a compromise between too much and too few events to collect.
To solve this problem, the suggested audit policy from adsecurity.org is checked against the audit policy in place.

Identify the Audit settings to apply and fix them.
Be aware that there are two places for audit settings.
For "Simple" audit configuration:
in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policies
For "Advanced" audit configuration:
in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration
Also be sure that the audit GPO is applied to all domain controllers, as the underlying object may be in a OU where the GPO is not applied.

10 points if present

https://adsecurity.org/?p=3299
[MITRE]Mitre Att&ck - Mitigation - Audit

The detail can be found in Audit settings
The table below shows the settings that were not found as configured in GPO for a given domain controller.

Hardened Paths weakness

A-HardenedPaths

The purpose is to ensure that there is no weakness related to hardened paths

Two vulnerabilities have been reported in 2015 (MS15-011 and MS15-014) which allows a domain takeover via GPO modifications done with a man-in-the-middle attack.
To mitigate these vulnerabilites, Microsoft has designed a workaround named "Hardened Paths". It forces connection settings to enforce Integrity, Mutual Authentication or Privacy.
By default if this policy is empty, if will enforce Integrity and Mutual Authentication on the SYSVOL or NETLOGON shares.
This rule checks if there have been any overwrite to disable this protection.

You have to edit the Hardened Path section in the GPO.
This section is located in Computer Configuration/Policies/Administrative Templates/Network/Network Provider
Check each value reported here and make sure that entries containing SYSVOL or NETLOGON have RequireIntegrity and RequireMutualAuthentication set to 1.
In addition to that, check entries having the pattern \\DCName\* and apply the same solution.

5 points if present

https://labs.f-secure.com/archive/how-to-own-any-windows-network-with-group-policy-hijacking-attacks/
https://talubu.wordpress.com/2018/02/28/configuring-unc-hardened-access-through-group-policy/
https://adsecurity.org/?p=1405
https://support.microsoft.com/en-us/topic/ms15-011-vulnerability-in-group-policy-could-allow-remote-code-execution-february-10-2015-91b4bda2-945d-455b-ebbb-01d1ec191328
[US]STIG V-63577 - Hardened UNC Paths must be defined to require mutual authentication and integrity for at least the \\*\SYSVOL and \\*\NETLOGON shares.
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

The detail can be found in the Hardened Paths configuration section.

Check if signing is really required for LDAP

A-DCLdapSign

The purpose is to check if signing is really required for LDAP

If the the request for signature of each LDAP request is not enforced, a man in the middle can be performed on an LDAP connection.
For example to add a user to the admin group.

This test is made by ignoring the local computer security policies.
Signature enforcement is done by setting the flag ISC_REQ_INTEGRITY when initializig the Negotiate / NTLM / Kerberos authentication.
The opposite test is made with the flag ISC_REQ_NO_INTEGRITY set.

PingCastle is testing if this setting is in place by performing a LDAP authentication with and without signature enforcement.
False positives may exists if the PingCastle program is run on the server tested that's why if PingCastle is run on a DC, the DC will not be tested.

You have to make sure that ALL LDAP clients are compatible with LDAP signature.
All supported Windows since Windows XP this into account and also most of the Unix clients.

You have to follow the Microsoft article quoted in reference to enable LDAP signing.
This includes auditing the clients which are not compatible and how to enforce this policy.

5 points if present

https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/enable-ldap-signing-in-windows-server
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536/page/4
https://github.com/zyn3rgy/LdapRelayScan
[MITRE]T1557 Man-in-the-Middle

Check that the "Pre-Windows 2000 Compatible Access" group has not been modified from its default

A-PreWin2000Other

The purpose is check that no additional account has been added to the "Pre-Windows 2000 Compatible Access" group

The pre-Windows 2000 compatible access group grants access to some RPC calls which should not be available to users or computers.

Remove the members from the PreWin2000 group while making sure that the group "Authenticated Users" is present. Then reboot each DC.

2 points if present

https://msdn.microsoft.com/en-us/library/cc223672.aspx
[FR]ANSSI - Use of the "Pre-Windows 2000 Compatible Access" group (vuln3_compatible_2000_not_default)3
[MITRE]T1110.003 Brute Force: Password Spraying

Check if the mitigation for CVE-2021-42291 has been enabled

A-DsHeuristicsLDAPSecurity

The purpose is to identify domains having mitigation for CVE-2021-42291 not set to enabled

The way an Active Directory behaves can be controlled via the attribute DsHeuristics of CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration.
A parameter stored in its attribute and whose value is LDAPAddAutZVerifications and LDAPOwnerModify can be set to modify the mitigatation of CVE-2021-42291.
The KB5008383 has introduced changes to default security descriptor of Computer containers to add audit and limit computer creation without being admin.
Indeed, it is recommended to not let anyone create computer accounts as they can be used to abuse kerberos or to perform relay attacks.

Mitigations in CVE-2021-42291 consist of 3 choices to be set on 2 settings.
They are named LDAPAddAutZVerifications and LDAPOwnerModify and are respectively the 28th and 29th character of this string.
For the expected values:
- With the value 0 (the default), it enables an additional audit mechanism
- With the value 1 (recommended), it enforces new security permissions, especially to require an action of the domain admin when unusual actions are performed
- With the value 2 (not recommended), it disables the audit mechanism that has been added by default and do not enable the new security permissions

The easiest and fastest way to correct this issue is to replace the 28th and 29th character of the DsHeuristics attribute.
The value of LDAPAddAutZVerifications and LDAPOwnerModify should be set to 1.

Open the procedure embedded into the KB5008383 to apply this mitigation and change the DsHeuristics value.

Note: you have to pay attention that there is control characters at the 10th and 20th position to avoid undesired changes of the DsHeuristics attribute.
Typically if the DsHeuristics is empty, the expected new value is 00000000010000000002000000011

Informative rule (0 point)

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
https://support.microsoft.com/en-au/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1
[MITRE]T1187 Forced Authentication
[FR]ANSSI - Dangerous dsHeuristics settings (vuln3_dsheuristics_bad)3

Check if LLMNR can be used to steal credentials

A-NoGPOLLMNR

The purpose is to ensure that local name resolution protocol (LLMNR) cannot be used to collect credentials by performing a network attack

LLMNR is a protocol which translates names such as foo.bar.com into an ip address. LLMNR has been designed to translate name locally in case the default protocol DNS is not available.
Regarding Active Directory, DNS is mandatory which makes LLMNR useless.
LLMNR exploits typo mistakes or faster response time to redirect users to a specially designed share, server or website.
Being trusted, this service will trigger the single sign on procedure which can be abused to retrieve the user credentials.

LLMNR is enabled by default on all OS except starting from Windows 10 v1903 and Windows Server v1903 where it is disabled.

Enable the GPO Turn off multicast name resolution and check that no GPO override this setting.
(if it is the case, the policy involved will be displayed below)

Informative rule (0 point)

https://youtu.be/Fg2gvk0qgjM
[MITRE]T1557.001 Man-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

The detail can be found in Security settings

Check if PowerShell logging is enabled.

A-AuditPowershell

The purpose is to ensure that PowerShell logging is enabled.

PowerShell is a powerful language, also used by hackers because of this quality. Hackers are able to run programs such as mimikatz in memory using obfuscated commands such as Invoke–Mimikatz.
Because there is no artefact on the disk, the incident response task is difficult for the forensic analysts.
For this reason, we recommend to enable PowerShell logging via a group policy, despite the fact that these security settings may be part of the workstation or server images.

Go to Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell
And enable "Turn on Module logging" and "Turn on PowerShell Script Block logging"
We recommend to set "*" as the module list.

Informative rule (0 point)

https://adsecurity.org/?p=2604
https://docs.microsoft.com/en-us/powershell/scripting/wmf/whats-new/script-logging?view=powershell-6
[US]STIG V-68819 - PowerShell script block logging must be enabled
[MITRE]Mitre Att&ck - Mitigation - Audit

The detail can be found in Security settings

Check the Password Policy for Service Accounts (Information)

A-NoServicePolicy

The purpose is to give information regarding a best practice for the Service Account password policy. Indeed, having a 20+ characters password for this account greatly helps reducing the risk behind Kerberoast attack (offline crack of the TGS tickets)
Note: PSO (Password Settings Objects) will be visible only if the user which collected the information has the permission to view it.

The rule is purely informative, as it gives insights regarding a best practice. It verifies if there is a GPO or PSO enforcing a 20+ characters password for the Service Account.

The recommended way to handle service accounts is to use "Managed service accounts" introduced since Windows 2008 R2 (search for "msDS-ManagedServiceAccount").
To solve the anomaly, you should implement a PSO or GPO password guarantying a 20+ length password.

Informative rule (0 point)

https://www.microsoft.com/en-us/research/publication/password-guidance/
[MITRE]T1201 Password Policy Discovery

The detail can be found in Password Policies

Check if NetCease has been put in place to mitigate Bloodhound

A-NoNetSessionHardening

The purpose is to ensure that mitigations are in place against the Bloodhound tool

By default, Windows computers allow any authenticated user to enumerate network sessions to it.
This means an attacker could enumerate network sessions to a file share hosting home directories or a Domain Controller to see who's connected to SYSVOL (to apply Group Policy) and determine which workstations each user and admin account is logged into.
Bloodhound uses this capability extensively to map out credentials in the network.

Disabling Net Session Enumeration removes the capability for any user to enumerate net session info (Recon).

If this mitigation is not part of the computer image, apply the following recommandations:
Run the NetCease PowerShell script (referenced below) on a reference workstation.
Open the Group Policy Management Console. Right-click the Group Policy object (GPO) that should contain the new preference item, and then click Edit .
In the console tree under Computer Configuration, expand the Preferences folder, and then expand the Windows Settings folder.
Right-click the Registry node, point to New, and select Registry Wizard.
Select the reference workstation on which the desired registry settings exist, then click Next .
Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity\
and select the check box for “SrvsvcSessionInfo” from which you want to create a Registry preference item. Select the check box for a key only if you want to create a Registry item for the key rather than for a value within the key.
Click Finish.
The settings that you selected appear as preference items in the Registry Wizard Values collection

Informative rule (0 point)

https://github.com/p0w3rsh3ll/NetCease
https://adsecurity.org/?p=3299
[MITRE]T1087.001 Account Discovery: Local Account

The detail can be found in Security settings

Check that the "Pre-Windows 2000 Compatible Access" group does not contain "Authenticated Users"

A-PreWin2000AuthenticatedUsers

The purpose is check if the "Pre-Windows 2000 Compatible Access" group contains authenticated users

The pre-Windows 2000 compatible access group grants access to some RPC calls.
Its default and secure value is the "Authenticated Users" group which allows users to perform group look up using legacy protocols.

If this group contains "Authenticated Users", it increases the impact on the exploitation vulnerability on legacy protocols such as the printer spooler.
Indeed, in the #PrintNightmare attack, it enables a patch bypass on domain controllers because the property Elevated Token is on when establishing a session to the DC.
Removing the group can have side impacts and as a consequence, this is reported here as a special hardening measure.

Remove "authenticated users" from the PreWin2000 group.

Informative rule (0 point)

https://msdn.microsoft.com/en-us/library/cc223672.aspx
https://www.gradenegger.eu/?p=1132
[MITRE]T1210 Exploitation of Remote Services

Check if Authenticated Users can create DNS records

A-DnsZoneAUCreateChild

The purpose is to check if Authenticated Users has the right to create DNS records

When a computer is joined to a domain, a DNS record is created in the DnsZone to allow the computer to update its DNS settings.
By design, Microsoft choose to grant to the group Authenticated Users (aka every computers and users) the right to create DNS records.
Once created, only the owner keep the right to edit the new object.

The vulnerability is that specific DNS records can be created to perform man-in-the-middle attacks.
One example is to create a wildcard record (a record with the name "*"), a failover DNS record or anticipating the creation of a DNS record with the right permissions.

As today this rule is considered as informative because the default configuration where Authenticated Users can create DNS records is considered safe.
The reason for this classification is that no exploitation of that vulnerability has been reported.

The proposed enhancement is to replace the identity who has been granted the right to create DNS Records (permission CreateChild) from Authenticated Users to Domain Computers.
To perform this change, you have to edit the permission of the DNSZone whose object is located in the container CN=MicrosoftDNS,DC=DomainDnsZones.

It should be noticed that if there is a privilege escalation on a computer, an attacker can impersonate the computer account and bypass this mitigation.

The best mitigation is to create the DNS records manually as part as the domain join process and to revoke the permission granted to Authenticated Users.

Informative rule (0 point)

https://www.ws-its.de/gegenmassnahme-zum-angriff-dns-wildcard/
https://www.netspi.com/blog/technical/network-penetration-testing/exploiting-adidns/
[MITRE]T1557 Man-in-the-Middle